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G. E. Valley, Jr. 


George E. Valley, Jr. (SM’55) was born in New 
York, N.Y., September 5, 1913. He graduated from 
the Massachusetts Institute of Technology, Cam- 
bridge, Mass., in 1935, and received the Ph.D. degree 
in physics from the University of Rochester, N.Y., 
in 1939. Following two years of post graduate re- 
search at Harvard University, Cambridge, he re- 
turned to M.LT. in 1941. - 

During the war he was project engineer for the 
H.X radar bombing system, the first American de- 
velopment of this type, which was used extensively 
by the U.S. Eighth Air Force over Europe and later 
by other heavy bomber units. In 1945 he served on 
the editorial board for the M.I.T. Radiation Labora- 
tory Technical Series. Returning to M.I.T. in 1946, 
he has been successively assistant, associate, and full 
professor of physics, and has conducted research 
in the fields of nuclear physics and cosmic radiation. 


A member of the Air Force’s Scientific Advisory 
Board since its inception, Dr. Valley was asked in 
1949, by the Chief of Staff, to undertake a special 
study of U.S. Air Defense. The ad hoc Air Defense 
Systems Engineering Committee, which he led as a 
result of this request, conceived the basic ideas of the 
SAGE System and was directly instrumental in the 
founding of the M.I.T. Lincoln Laboratory. Dr. 
Valley served as division head, assistant, and asso- 
ciate director of the Lincoln Laboratory and was in 
charge of the SAGE System. In 1957 he went on 
leave from M.I.T. to become Chief Scientist of the 
U.S; AiraBoree: 

He is a Fellow of the American Physical Society, 
and holds a Certificate of Appreciation from the 
U.S. Army, the President’s Certificate of Merit, the 
Air Force Association Science Award, and the Air 
Force Exceptional Civilian Service Award (twice). 
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Guest Editorial 


OME of the earliest proposals for the development 

of engines of war, complicated enough to be called 

“weapons systems,” were made during the Renais- 
sance by the great Italian painter, Leonardo da Vinci. 
Many people have looked at his drawings of tanks, air- 
planes, and other devices with amazement, not only that 
these should have been conceived so many years ago, but 
also that they should have been conceived by an artist. 

The writer has shared this feeling, but the more he has 
tried to understand what it is that systems engineers do, 
the less surprised he has become that Leonardo was an 
inventor, and the more he wondered why other systems 
engineers besides Robert Fulton and Samuel F. B. Morse 
have not also been artists by profession. 

For when a painter takes up his palette and brushes, he 
can create either a masterpiece or a daub; and so it is with 
the systems engineer. Each of these men must be able to 
synthesize a satisfactory pattern to be constructed largely 
from the components at hand—in the one case, canvas and 
paints, in the other, copper and cores and bits of crystal. 
Although the systems engineer is the captain of a team, 
whereas the artist works alone, he must nevertheless make 
the final decisions; there are relatively few successful sys- 
tems which were synthesized entirely according to the ma- 
jority vote in a committee. Nor will anyone who has man- 
aged the development of a system readily admit that the 


systems engineer requires less of that blind persistence 
in the face of seemingly endless frustration than does the 
artist starving in the proverbial garret. 

It may appear, then, that the quality of the painting 
depends more upon its creator’s vision and courage than 
upon his ability to run a paint factory. But history contra- 
dicts: for although we cannot say with certainty that any 
great number of masterpieces has been denied us be- 
cause the paint was of poor quality, we do know that al- 
most without exception the great masters engaged them- 
selves in the development of paint and other components 
of their art. 

And so it is with systems; the system which works and 
gives years of reliable service is scarcely ever the one 
which was engineered by a man so ignorant of components 
that he could not see to it that reliable, tested ones were 
used nor so optimistic that he allowed all of them to be 
specially invented for the immediate purpose. 

The above is by way of asserting that systems engineer- 
ing is an art; this statement cannot be proven. What can 
easily be demonstrated, however, is that the subject of 
systems engineering is notably lacking in one of the prin- 
cipal characteristics of a science. There is no general agree- 
ment on the definition of the words “system” and “systems 
engineering,” for one man’s “system” is another man’s 
“component.” It depends upon who you are and what 


Fig. 1—This photograph of the first U.S. bomber to carry an American-made radar bomb-sight may be of historical interest to readers. 
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you're doing. There are, for instance, the solar system, the 
banking system, and the nervous system. The writer’s 
conclusion from reading a good many of the attempted defi- 
nitions is that all of them can be logically extended to 
cover devices which are clearly not “systems” and clearly 
have not been “systems engineered.”” From this, one can 
only conclude that practically anything which can conceiva- 
bly be taken apart and put back together again can be 
regarded as a system, and that some place there exists 
someone who regards himself as competent to engineer the 
procedure. 

This reasoning shaped the make-up of the present issue 
of these TRANSACTIONS, Systems engineering was regarded 
as a skill to be learned from practice and from coaching by 
more experienced persons, like learning to play a game— 
or to paint a picture. 

One could not in consequence separate the issue into 
logical subdivisions of the over-all subject like an arith- 
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metic book. Instead, here is presented the experience of 
several systems engineers. What these men have acquired 
is not so much knowledge which can be dissected and set 
down piecemeal, but an entirely different mental attribute: 
the one we call wisdom. All the following papers, there- 
fore, bear essentially the same title. They are written by 
men of the highest stature and achievement in the field, 
men who have generously given their time to prepare these 
articles in the hope of passing on to the rest of us a little 
of what they have learned. 

The editor felt no obligation to delete repetitions of the 
same idea as expressed by the different authors, for if 
several men independently express the same opinion, it is 
probably truer than if only one does so; and certainly it is 
the more easily understood. For the opposite reason, there 
was no attempt to make the papers consistent with one an- 
other, or with this editorial. 

George E. Valley, Jr. 
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Systems Engineering and Weapon System Management* 
L. I. DAVIS+ | 


Summary—Weapon System Management is a term in common 
use. The author describes some of the problems encountered in 
developing complete air weapons for combat use. The design 
problems caused by introduction of jet engines, missiles, and com- 
plex electronic systems, in the post-World War II period en- 
gendered a developmental pattern which emphasized the need for 
integration of all components. System engineering, in the control 
engineering connotation, and operations analyses are necessary 
parts of the management of modern military weapons. 


sight in 1943. It was a “good gadget’—it per- 

formed well in engineering tests and was ex- 
tensively tested by stateside crews before release for com- 
bat use. Group commanders in England claimed improved 
scores when training new crews. But, over Germany, it 
was another story! Lead bombardiers, old hands, tried it 
a few times, then adopted the practice of turning it off on 
the final bombing run. 

This device was the automatic gyro leveling attachment, 
consisting of mercury switches which closed circuits when 
the gyro gimbals were not level, sending current through 
torquing solenoids which caused the gyro to precess to 
correct the condition sensed by the mercury switches. It 
was a substitute for the visual bubble levels used by the 
bombardier to erect the bombsight gyro to the apparent 
vertical. The operation of this gadget is a good example 
of the need for system engineering. Why lead crews 
turned it off during the bombing runs over Germany will 
be explained later in this article. 

The lack of success of the automatic gyro leveling de- 
vice illustrates the many lessons learned during World 
War II. The period immediately after the end of the war 
was a time of adjustment and appraisal. Military men 
shifted from the problems of demobilization to the job of 
analyzing the lessons of the conflict and the significance 
of air power on strategy and force composition. 

Aeronautical engineers learned a lot from the headaches 
of trying to make a combat weapon out of an assembly of 
airframe, engine, and equipment. One difficulty arose from 
the fact that airplanes are designed with the expectation 
that a certain thrust will be available at a specified altitude. 
If the engine propeller combination fails to deliver the ex- 
pected thrust, the airplane operates off the design point, with 
serious loss in aerodynamic efficiency, 

Another headache might be called “May and Decem- 
ber” marriages; for example, airframe and engine com- 
binations each representing the most advanced design prac- 
tice in its field, and compatible with each other, were loaded 


i NEW GADGET was added to the Norden bomb- 


* Manuscript received by the PGMIL, October 14, 1958. 
+ Major General, Office of Information Services, ARDC, An- 
drews Air Force Base, Md. 


down with equipment and armament that was of World 
War I design. 

Turning from engineering to administrative matters, 
scheduling problems were always plaguing the assembly 
plants. Long lead time items such as fire control systems, 
bombing systems, and engines were never delivered on 
schedule. This was inevitable because the airframe could 
be built and wrapped around the assembly almost as 
quickly as the salesman promised. The fact that the air- 
plane builder had no contractual control over the G.F.E. 
(government furnished equipment) added to the confu- 
sion. 

Ancillary equipment—ground support items such as trac- 
tors for towing, fuel servicing trucks, test instruments, 
and crew training devices were overlooked in provisioning 
the combat commands—or were not funded because their 
priority was not associated with the combat weapon it- 
self. 

Turning from some of the lessons learned in World 
War II to the problems posed by an advancing technology 
in the immediate postwar years, aeronautical engineers 
found 1) new propulsive devices—jet engines, ramjets, 
and rockets ; 2) new and demanding military requirements ; 
3) complex communications, radar, navigation, fire control, 
and bombing equipment; and 4) missiles and all the de- 
sign problems of complete automatic control. 

The new power plants were voracious in their consump- 
tion of fuel, and the thrust-speed-altitude relationships 
made possible a new regime of operation. These considera- 
tions led to many design studies, which surprised military 
planners, especially when they produced fighter designs 
that were heavier than the “heavy” bombers of World War 
II. As a consequence, designers questioned the practice 
of issuing “Military Characteristics” that specified range, 
altitude, minimum acceptable top speed, takeoff and land- 
ing roll, equipment to be carried, and engine to be used. 
They rightly claimed that such a rigorous description con- 
strained the design to a single end—and if the product 
was not what the military expected, the military should 
blame itself because industry could not change the laws of 
thermodynamics nor the laws of motion as set forth by 
Newton. ; 

The military “requirement” to carry 10,000 pounds 
10,000 miles brought Breguet’s equation’ out of the dust 
of the textbooks. As a result, design studies emphasized 
weight reduction, and every pound of equipment weight 
was questioned. Aeronautical design has always placed a 
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Fig. 1—Thor missile operational launching complex. 


premium on efficiency because each pound must carry much 
more than its own weight. An airplane built to the safety 
factors used in bridge design will not get off the ground. 
In addition, the loss in the propulsion efficiency term, be- 
cause of the new jet engine, brought more pressure to re- 
duce weight. Equipment designers were warned daily that 
each pound of extra weight carried to the target meant 
sixteen or twenty pounds more in takeoff gross weight. 
The problem is the same in missiles. An additional pound 
accelerated to warhead velocity means fifty pounds addi- 
tional in the lift-off weight of a ballistic missile. 

About this time (1948) the term Weapon System Man- 
agement began to be used in the Engineering Division of 
the Air Materiel Command of the USAF as a result of 
the lessons learned in World War II and the problems 
posed by the new jet engine, missile, A-bomb technology. 

This term was the outgrowth of discussions held among 
the engineering laboratories, the aircraft and missile proj- 
ect offices, and engineering management in the persons 
of Generals Chidlaw, Craigie, Crawford, and Putt. The 
laboratories, conscious of the critical nature of system 
designs in which coupling and feedback caused dynamical 
problems, pressed for the establishment of an agency 
responsible for “systems” engineering. The aircraft and 
missile project offices recognized this need and, in addition, 
the administrative problems of scheduling long lead time 
items, ancillary equipment, and training devices. Engineer- 
ing management recognized these problems and also the 
problems of system optimization in a combat as well as in 
an aerodynamic sense. 

The word “Weapon” emphasizes efficiency in combat 
as the goal. The word “System” emphasizes the desire to 
integrate all elements—to have a complete package to de- 
liver to the using combat command. The term ‘“Manage- 
ment” implies the sound administrative practices required 
to plan all elements and to schedule components, testing, 
ancillary equipment, and training. 

Consideration of the tremendous job of integrating into 
one complete design the characteristics of tens of thou- 
sands of components, the procurement of parts on subcon- 
tracts, the scheduling of long lead time articles, the paral- 
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Fig. 2—Thor missile shortly after launching. 
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lel development of ground handling and test equipment, 
plus the very specialized talent required for operational 
and systems engineering studies, lead to only one solu- 
tion: develop weapon systems by a prime contract with 
one agency, with a “weapon system manager.” 

Industry, at least those firms which had the breadth and 
depth to compete, welcomed this procedure. They had a 
sincere desire to do a good job by furnishing to the military 
a really integrated weapon. In addition, the aircraft in- 
dustry noted the growth of expensive “equipment.” The 
airframe of the B-17 accounted for 78 per cent of the 
cost of the combat weapon; however, the airframe of the 
B-47 cost less than 50 per cent of the weapon delivered by 
AMC to the Strategic Air Command. So the profit motive 
entered the picture. 

Industry gladly accepted weapon system management. 
It joined its voice with that of the military (which was 
patting itself on the back for putting the monkey on some- 
one else’s back). The chorus of mutual congratulations 
swelled so high that the idea acquired the dubious label 
of “Weapon System Concept.” 

So many articles have been written and speeches de- 
livered about the “Weapon System Concept” that the need 
and the origin have almost been forgotten. The need arose 
from vital systems engineering problems, and the origin 
of the term came from a desire to manage the planning 
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and scheduling of a combat weapon as a complete system. 

Today, ten years after the origin of the term, we can 
assess the value of the practice with knowledge based on 
experience, not theory. In those cases where weapon sys- 
tems management has been successful, we see a proper 
balance of emphasis on all aspects of the total problem. 

Before “cutting tin,’ four types of studies are required. 
“Operations analysis” studies analyze the military problem 
and attempt to express in quantitative terms the gains or 
losses in over-all mission preformance effected by emphasis 
on this or that element of performance. 

An example might be cited from our experience in the 
Korean War. We can look back on the battles between the 
F-86s and MIG 15s and, with the exquisite accuracy of 
hindsight, point out that the probability of success in aerial 
combat is the product of four serial probabilities. The proba- 
bility of success of a combatant, after the enemy aircraft 
has been sighted, is the product of the probability of being 
able to maneuver into position, the probability of closing 
to effective range, the probability of hitting the target and 
the probability that those hits are lethal. The final product, 
the probability of success, is very sensitive to the weakest 
link in the chain P, = Py. X< Pe < Pu < Pip. The MIG 
15 had better altitude, acceleration and turning radius than 
the F-86 plus a cannon with explosive shells. The weak 
link was the probability of hit term. Under the very dy- 
namic conditions of high-speed jet combat, a good opera- 
tions analysis study would show emphasis should be placed 
upon the fire control equipment which assists the pilot in 
aiming his guns. The F-86 was equipped with automatic 
radar ranging and a gyro gunsight designed by C. S. 
Draper of M.I.T. Automatic range finding relieved the 
pilot of estimating or visually measuring range by stadia- 
metric means, and the gyro computing gunsight computed 
the correct lead in inertial space coordinates with minimum 
dynamic error. The final box score on F-86 vs MIG en- 
gagements shows a ratio of about 15 to 1 in favor of the 
fighter with the more sophisticated fire control equipment. 

The second type of preliminary study is the classical per- 
formance study on range, altitude, speed and payload with 
the propulsion units available. 

The third type of study concerns itself with system 
dynamics—commmunications, computation, data process- 
ing and control. Accuracy studies lie in this class because 
of their dependence on the analysis of dynamic error 
introduced in data handling, computation and control. If 
system dynamics are ignored, the kind of trouble is ex- 
perienced that was encountered when the automatic gyro 
leveling device was introduced into combat. 

The fourth type of study before engineering models 
are constructed deals with research on the state of develop- 
ment of component parts. The decision to start a full 
fledged weapon system project should be made on the 
basis that the probability of successful solution of unknown 
features of the design is reasonably high. If management 
chooses “off the shelf” “proven” components, or waits till 
all components are thoroughly tested, the final product 


January 


will be obsolete when it reaches the field. If, on the other 
hand, management elects to introduce too many new de- 
sign features, the probability of success is rather low, and 
the probability of meeting operational dates approaches 
zero. It has been said that we cannot schedule invention, 
that some things require a fixed gestation time, and the 
period is not shortened by putting more people and money 
on the problem. 

After the design of the weapon has been agreed upon, 
and fabrication has begun, “weapon system” management 
can look to the details of ground handling equipment, fuel 
servicing equipment, checkout consoles and other logistic 
support items. Crew training must be scheduled in advance 
of equipment, of course, but the actual training must wait 
until prototypes are available, and until experience with 
developmental testing reveals the methods and skills re- 
quired. 

Developmental testing is more than “proof testing” of 
a model. Modern high-performance missiles are much more 
sophisticated than a mere assembly of tested parts. Each 
part is designed to carry its load and perform its function 
with minimum weight and power. If the original design 
does not fail when first subjected to full-scale load tests, 
it was probably overdesigned. Developmental testing is a 
process of probing for weaknesses, redesign, refabrication 
and retesting, first of prototypes, then of articles made by 
production tooling. 

Good system management plans for thorough testing 
for fabrication of sufficient articles so that the testing can 
be done in parallel; it recognizes that performance is af- 
fected by production methods, tooling, and quality control 
as well as engineering design. Therefore, the testing phase 
is not complete until the product of the production line 
has been handled by combat troops in an operational en- 
vironment. 

In this connection it is appropriate to emphasize that a 
proper balance between component and complete system 
testing is necessary. If system testing is delayed until 
elaborate component testing is complete, the over-all cycle 
is unnecessarily extended. Although system testing is more 
expensive, there are a great many component as well as 
system weaknesses that will not be found until complete 
systems are tested on the ground and in flight. 

On the other hand, in those cases where systems pro- 
duced by “weapon system” management have failed, we 
see attempts to short-cut the foregoing studies and steps. 
In most cases the attempt to buy time with money pro- 
duces unreliable systems much later than the operational 
dates promised. Management, unskilled in system engi- 
neering, attempts to break down the design in many com- 
ponents, to be produced in parallel. Many times it is “easy 
to do it the hard way” producing overly complex solutions 
to problems that are relatively simple when reviewed from 
a total system viewpoint. On the other hand, a really so- 
phisticated design cannot be achieved without extensive 
system engineering studies to determine the required per- 
formance of each component, plus the nature of the inter- 


1959 


action of components upon the performance of the whole. 

The interaction of the performance of components when 
assembled into a system and operated in the geometry of 
the combat situation brings us ‘back to the example used 
in the introduction of this article. 

Why did the automatic gyro leveling attachment fail to 
perform satisfactorily over Germany? 

The system, consisting of the gyro (which stabilized 
the bombsight optics), the bombardier, the auto pilot, the 
airplane and the gyro leveling attachment, had a definite 
feedback path. The bombardier, in keeping the crosshairs 
of the optics on the target, sent signals through the auto 
pilot to correct the heading of the airplane. The accelera- 
tion of the plane as it changed its heading was sensed by 
the mercury switches of the leveling device and inter- 
preted as a change in the apparent vertical. This in turn 
caused the gyros to precess—moving the optics. The sense 
of the correction appeared to be degenerative or stable if 
one ignored phase shifts, and certainly there was nothing 
that looked like tight coupling or high gain in the system. 

When the phenomenon of hunting or oscillating on high 
altitude bombing runs was reported to the Armament 
Laboratory in 1944, a stability analysis was made. The 
methods used were those set forth in den Hartog’s text, 
“Mechanical Vibrations.’”” When the geometry of the 
problem, the phase shift in gyro precession, erection rates 
and reasonable assumptions about response times were 
cranked into Routh’s stability criteria, it was apparent that 
stability was a function of altitude. To the electrical engi- 
neer the 90° phase shift in the gyro part of the loop would 
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be obvious and a danger signal. The “gain” around the loop 
does not become apparent until a study of the geometry of 
the action shows the airplane pivoting about a radius that 
is the projection on the vertical of the line of sight to 
the target. The greater the altitude, the greater the radius 
and acceleraion. Thus, the “gain” increases with altitude— 
and at the extreme altitudes of the combat bombing runs 
over Germany a low-frequency hunt or oscillation was 
experienced. Experienced bombardiers broke the feed- 
back loop by turning off the automatic device. They 
leveled the bombsight by visual reference to the bubbles 
when the plane was in straight and level flight. 

“Weapon System” management has been outstandingly 
successful in the ballistic missile program. This has not 
been achieved by a single prime contract, nor by “concepts” 
or programs or printed schedules. The success is due to the 
fact that systems engineering is done under a separate con- 
tract. General Schriever has in effect raised it to top man- 
agement status, and objective studies and research can be 
conducted unbiased by sales and production pressures. 
Schedules on subcontracted items and comprehensive test- 
ing can be established in that same atmosphere. 

The bright and shining label “Weapon System Concept” 
will not solve our system engineering problems, nor will 
it change the fact that it takes twice as long to develop a 
missile propulsion plant as it does to wrap the tin around 
it. The work that needs to be done still has to be done by 
people who deal in facts, not labels and who have the train- 
ing and experience and patience to find simple but sophisti- 
cated solutions to complex problems. 
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Systems Engineering for Usefulness and Reliability* 
W. C. TINUS} anv H. G. OCH} 


Summary—With the increasing complexity and cost of weapon 
systems, it is becoming ever more important to provide a product 
that will be useful to the customer, that will provide reliable 
service, and that will have growth capabilities so that its useful 
life can be prolonged to meet the ever increasing enemy threat. 
The management of the research and development program for 
such large projects must provide detailed and careful planning 
and control in order to produce an integrated system on a mini- 
mum schedule. 

System approach, now the byword of the electronic industry, 
means many things to many people. To the authors of this paper, 
it is the orderly arrangement of many details that are necessary 
to the sound planning of a large development effort. 


DEALLY, a development program results in equip- 
| ment which comes into operational use at the time it 

is needed and performs its intended functions well, 
serves its user with a practical maximum of reliability and 
has a long operational life due to adequate foresight in its 
concept and inherent growth capability in its design. Ad- 
ditionally, the ideal development is carried out at reason- 
able cost and the design lends itself to economical manufac- 
ture and maintenance. 

It is hardly necessary to say that if all development proj- 
ects could come closer to this ideal, much faster technical 
progress could be made and much less development effort 
would be wasted. 

It has become more and more apparent in recent years 
that better over-all planning before large development 
effort is expended and better checking of plans throughout 
the development interval, are the only ways to make the re- 
sults of large development efforts more nearly approach 
the ideal. 

The basic prior planning of developments and the con- 
tinuing detailed adjustments of these plans during develop- 
ment to insure a well-balanced outcome are the heart and 
soul of systems engineering. In this paper, the authors have 
undertaken to discuss in some detail the course of a large 
development in an effort to illustrate the controlling effect 
on the outcome of good planning at every step along the 
way. 

A well-planned system development program can be di- 
vided into six major phases as follows: 


1) Study phase 

2) Proposal evaluation 

3) System design 

4) Equipment design 

5) Model construction and test 

6) Completion of manufacturing information. 


* Manuscript received by the PGMIL, October, 1958. 
+ Bell Telephone Labs., Whippany, N.J. 


Generally, these steps follow in chronological order. How- 
ever, many of the detailed steps actually overlap and even 
recur during the development program. 


STUDYING THE PROBLEM 


Let us begin by examining the first step of our pro- 
gram—the study phase, in which the problem which the 
customer wants solved is considered. It may be a very con- 
crete problem, and he may have a proposed solution to it 
which he wants carried out. On the other hand, it may be 
a very vague problem which has yet to be explicitly stated. 
The systems study engineers must first attempt to under- 
stand the problem thoroughly and to state it explicitly. It 
must be defined clearly in relation to other surrounding 
problems, and solutions should be proposed which are com- 
patible with the surrounding problems. The comparison of 
different possible solutions must be made on the basis of 
both technical and economic analyses. A proposed solution 
must be subjected to such broad questions as “Is it timely 
to undertake any solution to this problem?” and “Who is 
best qualified to undertake it?” 

In the case of defensive military systems, an evaluation 
must be made of the expected threat in the time period 
when the equipment will be deployed. Similarly, in the case 
of offensive weapons, the probable defense posture of the 
enemy must be examined again as of the time period when 
the equipment will be operational. Only through careful 
and objective comparison of the opposing capabilities, at a 
future realistically estimated time, can reasonable assur- 
ance be had that the equipment to be designed will not be 
obsolete before it finds usefulness. Added insurance can 
be obtained, of course, by providing, wherever possible in 
the design, the potential for growth and extension of the 
design to keep up with the ever-advancing military tech- 
nology. 

In the study phase, it is of extreme importance to evalu- 
ate objectively the state of the art available for the project. 
If a major advance in technology is undertaken, it is neces- 
sary that the state of the art be pushed with attendant extra 
risks. On the other hand, if a completely reliable system is 
the objective, techniques and devices which are completely 
proven and are in the state-of-the-art stockpile must gen- 
erally be used. The first approach, if carried to extremes, 
would move technology forward with giant strides without 
ever producing reliable equipment which could be de- 
pended upon to function when it is most needed. The sec- 
ond approach, if carried to extremes, would eventually 
result in being far behind in the technological race. Ob- 
viously, a compromise is needed, using as many of the 
techniques and devices “off the shelf” as possible, while 
pushing the state of the art forward in a relatively small 
number of areas where such advances are most urgently 
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needed. In making the choice of these areas, it is important 
that concentrated effort be available and applied from the 
very outset to the major unknowns of the project in order 
to insure the proper meshing of the development schedule. 

The study phase is for gathering ideas. One approach 
for getting all the hopefully bright ideas on the table is 
to rule out all evaluation whatever until all the ideas, pre- 
posterous or not, are on display. This technique is most 
useful in cases where there is a shortage of ideas for con- 
sideration. As all available ideas are boiled down and in- 
terrelated, it becomes possible to define the kind of subsys- 
tems that are needed and to determine tentative require- 
ments for these subsystems. The backbone of this skeleton 
of ideas is the plan for time sequential or tactical operation 
of the system. The mission for the system must be out- 
lined in a step-by-step fashion starting from turn-on of 
the equipment to “mission accomplished.” Without such 
correlation, the equipment units in a system degenerate into 
a group of interconnected “black boxes” which are separate 
entities and do not comprise a system. 

When the system skeleton begins to take form, it is time 
to make a preliminary analysis of system capability. This 
consists of rough estimates of accuracy, fire power, and 
such other parameters as are necessary to assure that the 
conception of the system will be satisfactory. If these es- 
timates show adequate performance capability, and it is 
reasonably certain that a better approach has not been over- 
looked, it is timely to proceed with more detailed considera- 
tions. 


EVALUATING THE PROPOSED SOLUTION 


The second phase of development may be called a com- 
plete evaluation of the recommended system. This evalua- 
tion is essential and must be carefully conducted to fur- 
nish an enduring foundation for the large development 
effort to follow. It must be made with the advice and as- 
sistance of the equipment design engineers, who will later 
do the detailed design work, and must go into considerable 
depth of analysis of the subsystems in order to insure feasi- 
bility of the system plan. Over-all system performance re- 
quirements must be continually reviewed in the light of 
these more detailed analyses of the subsystems and com- 
ponents in an attempt to uncover basic technical or eco- 
nomic conflicts. When such conflicts are revealed it is 
necessary to propose means for designing around them, or 
to revise requirements to maintain an economic balance. 

In this re-examination, a great deal of detailed attention 
must be given to the human engineering aspects of the sys- 
tem, from the standpoint of fitting the machine to the op- 
erators. A careful look must be taken at the proposed divi- 
sion between automaticity and human decision. Time analy- 
ses must be made to interleave the operations accomplished 
by the human operators and the machine. The proposed 
tactical operation of the system may have to be rearranged 
in order to minimize total time needed for the mission 
or to prevent even momentary overloading of a human op- 
erator. Displays and controls must be worked out in prin- 
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ciple if not in detail to study the probable reaction of hu- 
man operators to the stimuli of the indicators: Much 
thought must be given to accomplishing the mission with 
a minimum of operational controls. 

At this point in a development project, it is important 
to undertake a preliminary assessment of the reliability of 
the recommended system. The reliability of the system, 
of course, depends primarily on the reliability of the com- 
ponent parts, all of which can only approach but never 
achieve 100 per cent reliability. It must be remembered that 
new ideas for components, or new design techniques, while 
providing greater technical capabilities, will generally not 
provide an immediate improvement in reliability, As a 
matter of fact, new components and design concepts usu- 
ally introduce new problems and reduce reliability for some 
time. The eventual reliability of new components is gener- 
ally better than the reliability of those they replace. How- 
ever, this results only after experience is accumulated— 
experience in methods of manufacture, experience in 
proper design use of the unit, and experience with the 
unit in an operating system under actual field environ- 
mental conditions. 

Of critical importance in estimating reliability is a knowl- 
edge of environment. Temperature, humidity, shock, vi- 
bration, pressure, and other elements of environment dur- 
ing shipment, storage, and use must be estimated so that 
realistic evaluations of component reliability can be made. 
Estimates of mean time to failure for the system are es- 
sential for comparison with the total mission elapsed time. 
Inherent potential weak points in the system must be ex- 
amined and a start made in the planning for maintenance 
procedures and maintenance test equipment. 

The recommended system must also be critically ex- 
amined in this period to determine if it can be adequately 
maintained as it will be deployed in the field. Will it be 
practical to bring test equipment to the system when needed ? 
How much built-in test facilities should be provided? Do 
the size and weight and operating requirements permit 
intricate built-in test equipment? Should only “Go-No Go” 
test facilities be provided? What are the expected technical 
qualifications of the operators? of the maintenance crew? 
These and many other questions have to be satisfactorily 
answered before it is reasonably certain that the recom- 
mended system will be an effective one for the customer’s 
use. 

Based on this more detailed study of the proposed sys- 
tem, it is important to re-examine the tentative schedules 
for the project with respect to its prospects for meeting 
the expected enemy capability at time of deployment. One 
of the most critical scheduling problems has to do with the 
technical advances required in the state of the art for com- 
pletion of the project. A careful assessment must be made 
of the probability that the necessary technical break- 
throughs will be accomplished in time for use in the proj- 
ect. Obviously, this is an area of calculated risk and the 
project can rise or fall if judgment on this is wrong. This 
is generally the only area where any consideration should 


10 IRE TRANSACTIONS ON 


be given to parallel developments for insurance of success, 
and the less desirable alternates carried along in develop- 
ment must also be capable of meeting the system require- 
ments or the project is in grave jeopardy. 


OUTLINING THE SYSTEM 


Having accomplished this close scrutiny of the recom- 
mended system plan and having found all factors favor- 
able, it is now possible to prepare a complete specification 
of performance requirements. This is the first major step 
in the establishment of a firm development plan for system 
design. If the project has been properly handled, this docu- 
ment has already been in process from the very beginning. 
During the study and evaluation stages, it has become more 
elaborate and now attains its full maturity in the project 
as the project “Bible.” When reproduced for each group 
of subsystem designers, it will become the designer’s guide 
and will furnish the basis for detailed compatibility at the 
interface between subsystems. 

During the development processes just described, it is 
important that all important changes in system objectives 
be cleared with the customer. Weapon systems usually start 
with a set of objectives which are highly desirable but 
probably not completely attainable. It is often necessary 
that the objectives be modified to a level attainable in the 
program time scale. This frequently requires the deletion 
of superfluous emergency modes and operational frills 
in order to make the design simpler and more practical 
from a reliability and maintenance standpoint. 

The development plan must include a system philosophy 
to be followed regarding reliability of components. The 
development organization may already have established 
reliability standards; however, these are generally broad 
in nature and it is necessary that the project spell out stand- 
ards which are tailored to its specific environmental con- 
ditions. These will include guides for choosing components 
of known reliability and the derating factors that are to 
be used throughout the design. When components must be 
used whose performance and reliability are unknown, suit- 
able environmental tests must be made and changes in com- 
ponent designs undertaken to insure the consistency of 
these elements with the rest of the system. 

The ever increasing complexity of our military systems 
has emphasized the importance of minimizing the number 
and type of manual operations. The development plan 
for a system must, therefore, include firm requirements 
on the types and numbers of controls so as to leave the 
human operators as free as possible to make their major 
decisions. A system that has too many maintenance adjust- 
ments is apt never to be ready when needed, It is important 
that the maintenance philosophy and planning for test cir- 
cuitry be available at the beginning of the design period 
so as to produce a uniformity and optimization of the 
field maintenance procedures. 

It will be obvious that in setting up the philosophies for 
reliability and maintenance, a number of system _per- 
formance compromises will have to be made. These may, 
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of course, be reflected by minor changes in the project 
“Bible” and modifying what was a too optimistic per- 
formance to a more practical and reliable level. 

On any large job, a system generation breakdown chart 
is required. This is a chart naming the subsystems and their 
further subunits so that the assignment of tasks to various 
development groups can be made. The division into sub- 
units must be made in a way which will produce a sepa- 
rately manufacturable and testable unit for which an in- 
dividual test specification can be written. A set of require- 
ments for each unit can be made available for all groups 
working on the project, showing what each unit is ex- 
pected to do and insuring compatibility at the interfaces 
between units. As the designers proceed and find that 
changes need to be made, these specifications must be kept 
up to date. It is always possible then for the system co- 
ordinating group to evaluate the current expected per- 
formance of the system. 

It is essential that complete schedules for the project be 
provided and maintained, highlighting all significant mile- 
posts for the basic development, prototype, and produc- 
tion phases of the project. Each identifiable unit on the 
generation breakdown chart must be scheduled for electri- 
cal design, brassboard, laboratory test, mechanical design, 
model test, subsystem test, and any other significant pro- 
gram check points. 

Since the project organization is usually not equipped 
to design all subsystems, units, or components required 
in the system, a plan for subcontracting design effort and 
model production is necessary. It is essential that all 
schedules and specifications be completely agreed upon with 
properly qualified subcontracting groups in the same or 
other companies. : 


DESIGNING THE EQUIPMENT 


Now an all-out effort is applied to the actual detailed elec- 
trical and mechanical design of the system components. 
Prior to this phase, there has been a concerted attack on the 
most difficult problems—those requiring major technical 
advances in the art. Also, prior to this point there may have 
been several areas where parallel approaches were being 
studied so as to insure the most effective solution. These by 
now must be resolved to a single approach, with enough 
emphasis to insure success in the time period. 

Throughout the design phase, there must be a more or 
less continual re-evaluation of system performance and 
subsystem specifications to maintain compatibility of de- 
sign and effect necessary compromises. The amount of this, 
of course, will depend primarily on the difficulty of the job 
and the degree of success the individual designers attain 
on each subunit of the system. A program of periodic 
meetings of all supervisory personnel on the project is 
helpful in accomplishing this aim. These meetings may be 
held on a bi-weekly basis and should be limited to about a 
two-hour period. Each is led by the project group, and the 
technical material covered in each meeting is specific to a 
single area or subsystem. A brief discussion of the objec- 
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tives and attainments usually uncovers minor incompatibili- 
ties and misunderstandings which can then be worked out 
in detail by the particular engineers concerned, without 
appreciable wasted effort. These meetings are helpful in 
maintaining fluidity of thinking in the project and permit 
even major modifications if and when unexpected technical 
break-throughs do occur. These meetings also serve to keep 
the project manager and his system-design group com- 
pletely informed on progress in each area. These meetings 
should not, however, take the place of the day-by-day dis- 
cussions that are necessary between the designers of sub- 
systems which are interrelated or have common interfaces. 

During the design phase, as brassboard models are 
created and tested, it is important that the results of these 
tests be fed back to the system planning group so that they 
can perform their function of re-evaluation. As the tests 
progress, individual designs should be frozen as soon as 
adequate performance is in sight, so that the final drafting 
can get under way. No project can afford time to comb 
out all of the minor bugs from subunit design before start- 
ing the drawings for a true prototype model. Good judg- 
ment has to be exercised and calculated risks taken in de- 
ciding when a design is adequate. The detail frills can be 
ironed out during the time that the design is on the draft- 
ing board, or even while the prototype models are under 
construction, 


MopELs AND MANUFACTURING INFORMATION 


Most military jobs are rush jobs and the last two phases 
in the development program generally occur more or less 
simultaneously. These involve the construction and testing 
of the models of the system and the completion of manu- 
facturing information. If everything were ideal, the draw- 
ings provided for building of these models could be used 
directly as a major part of the manufacturing information. 
However, problems are always uncovered in the fabrica- 
tion of the models, and operational difficulties are bound 
to occur during the test of these models. It is necessary 
to feed back information quickly and accurately to the 
drafting groups so that manufacturing information can 
be completed. 

A well-developed plan of test is needed proceeding 
through unit tests and subsystem tests to system tests. In 
each case, there will be the usual de-bugging stage, fol- 
lowed by tests which will completely cover the per- 
formance of the unit with respect to its electronic, me- 
chanical, environmental, and human engineering require- 
ments. The planning for the model program should have 
provided enough models of each unit, subassembly, sub- 
system, or system, to allow for shock, vibration, tempera- 
ture, and humidity testing, as well as life testing of critical 
units. Past experience has generally shown that most types 
of equipment should be thoroughly life tested as early as 
possible in the model program. Short life of components 
discovered too late can produce an insurmountable logistics 
problem for the customer during early deployment and can 
result in a serious tactical situation. 
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DEVELOPMENT MANPOWER 


So far, the stages of development have been discussed 
with little reference to the organization of manpower re- 
quired for such development. Some comment is in order 
on the organizational structure of the project and the kinds 
of people that are needed. It goes almost without saying 
that the kinds and number of people needed will vary 
throughout the project. 

The success of a project depends very heavily on the 
choice of and the responsibilities invested in the project 
engineer, The size of the project should have an important 
bearing on the level of management vested with this re- 
sponsibility. Placing the responsibility too low in an or- 
ganization can be a limitation on the project engineer with 
respect to the delegations of authority he needs to conduct 
the job effectively. Placing the responsibility too high in an 
organization relegates the project to a position of sharing 
with many other duties the attention of the project man- 
ager. 

It is not necessary here to dwell on the particular capa- 
bilities of the project manager. He must deal with many 
people including customer representatives, engineers, and 
subcontractors and obviously must have a background of 
training and experience to enable him to understand their 
language and their problems. 

In a project of any substantial size, the project engineer 
needs a system design group to assist him in coordinating 
the efforts of all other groups and subcontractors. This 
group will ordinarily constitute about 5 to 10 per cent of 
the total personnel on the project and will vary in size 
and in composition with elapsed time. For example, in the 
study phase this group needs people of high analytical abil- 
ity and keen insight into the customer’s problem, mixed 
with a smaller number of experienced development en- 
gineers. Some members of the team may necessarily have 
their heads in the clouds since they may be working on the 
forefront of knowledge, while others in the group must 
keep their feet firmly on the ground if a practical recom- 
mendation is to ensue. 

As the project progresses to the proposal evaluation 
stage, the bright ideas must be subjected to a searing ex- 
amination by dedicated critics whose purpose is to deter- 
mine objectively if the bright ideas are really bright when 
examined from all pertinent angles. The systems group 
must thus include one or more pessimists who must be well 
informed in the applicable scientific fields and perhaps be 
even better informed about the practical problems involved 
in reducing ideas to practice. The critic may be an old timer 
who has learned by long experience how to take a con- 
structive negative attitude toward a proposed idea, or he 
may be a youngster with a special talent for asking embar- 
rassing questions. Mutual respect can be maintained be- 
tween proposer and critic by having them change roles on 
different jobs or even on different aspects of the same 
job. 

The characteristics of the systems group will continually 
change and eventually, at the field test phase of the pro- 
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gram, it will be made up of people having particular capa- 
bilities in field testing operations and who are experienced 
in dealing with the customer at military proving grounds, 
firing ranges, or military test sites. The specific assignments 
and responsibilities of the group as the development job 
progresses may be listed as follows: 

1) System performance requirements 

2) Maintenance capability 

3) Economic balance 

4) Continual evaluation and analysis of system per- 

formance 

5) System test specifications 

6) Conduct of field test and analysis of results. 

This emphasis has been put on the systems design group 
because of its importance in the processes of planing and 
in directly assisting the project engineer. However, as pre- 
viously indicated, it ordinarily constitutes only a small 
portion of the people required for the enterprise as a 
whole. 

As the project gets into the detailed equipment design 
phase, the effort rapidly mushrooms to include many 
people new to the project. Assuming that planning has been 
good up to this point, there is still a very great need for 
good management from here on out if the development is 
to proceed with efficiency and on schedule. Only a few of 
the points involved will be discussed here. 

First, responsibility for every unit and subunit in the 
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whole systern must be assigned to a specific individual. 
He must understand that he is undertaking to meet the 
technical requirements and to meet them on the assigned 
schedule. It is clearly his duty to sound the alarm to the 
project leader as soon as he suspects that a precarious 
situation is arising. 

Second, the best qualified available talent should be as- 
signed to the various portions of the job. This frequently 
means getting outside help by subcontract and resisting 
the urge to do everything within the organization. 

Third, the easy parts of the job must be held in step 
with the hard parts. To let the easy parts proceed at maxi- 
mum rate may look like fast progress on the job as a whole, 
but usually results in inefficiency when the problems on the 
hard tasks demand changes. 

Good fiscal management and planning is just as essential 
to the success of a development as good technical planning, 
but cannot be discussed further in this brief paper. 


CONCLUSION 


This paper has discussed some of the many facets of 
good project management, an important contribution in the 
development of useful and reliable equipment. Systems 
engineering, which many have found so difficult to define, 
may really have no better definition than simply all the 
things one has to do to insure a sound plan for carrying 
out a large development effort. 


Systems Engineering* 
R. H. JEWETT+ anv R. A. MONTGOMERY+ 


Summary—A description is given of practical systems engineer- 
ing methods as applied to large military systems in an industrial 
environment. Particular emphasis is placed on a design approach 
which stresses minimum interconnections between subsystems 
and on system testing methods. Also discussed are system evalu- 
ation, management, and costs. 


INTRODUCTION 
A “SYSTEM,” for the purposes of this article, may 


be defined as an assembly of equipments or com- 

ponents chosen, arranged, and operating together 
so as to accomplish a certain defined task. This task is the 
“mission” by the military definition, or simply the “job” in 
a business sense. A system may contain other systems, 
which are then called subsystems. For example, a telephone 
network is a system insofar as it meets communication re- 
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quirements ; however, it is a subsystem when considered as 
part of an air defense system. 

The nation’s railroads are good examples of early large- 
scale systems. Such systems included rights of ways, 
tracks, rolling stock, fuel, stations, trainmen and other per- 
sonnel, personnel housing, tunnels, bridges, and many 
other constituents. Railroad promoters who were poor sys- 
tem designers, either in choice of market or ability to 
meet competition, failed. This element of competition pro- 
vides the only real criterion of successful system design 
and will be discussed in this paper. 

In industry, teams of engineers are required for each 
of the principal systems engineering functions, viz; design, 
management, evaluation, and testing. Members of each of 
these teams must all approach their jobs with a healthy 
respect for, and understanding of, the other facets of sys- 
tems engineering, 
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Systems engineering, in particular, is evolving as a dis- 
tinct branch of engineering practice. The systems engineer 
bases a new system design on known fundamental physical 
capabilities—future inventions cannot be scheduled for 
inclusion. The systems engineer must also leave the detail 
design of subsystems to others. Constrained from specializ- 
ing, he must be skillful in interpreting the potentials and 
limitations of alternate system configurations, 

The experience of the authors has been primarily with 
large-scale military systems for air defense purposes. Their 
work has been carried out in an industrial environment 
under continuous competitive pressure. It is hoped that 
this paper will convey some of the lessons learned. 


PROBLEM FORMULATION 


Successful systems result from applications of tech- 
nology at a specific time to a “mission” of current and 
continuing importance. An organization, in order to com- 
pete, must have internal or external access to the tech- 
nological possibilities in each of many scientific and engi- 
neering fields and must also provide the special skills in 
synthesis required to select critical elements. The synthesis 
work is generally done under competitive pressure: either 
direct competition for a contract, or indirect competition 
for the same available funds. 

A system is engineered with in certain limitations. Fig. 
1 diagrams the constant pressure upon these boundaries. 


Application 


1 
ea Requirements 


Function 


Constraints 


Fig. 1—Forces affecting system design. 


Principal pressures are: 

1) Function—what the system has to be designed to ac- 
complish. 

2) Application—the environment in which the system 
must function. 

3) Requirements—the special features which the sys- 
tem must contain to satisfy the customer. These may 
include compatibility with other systems, use of other 
systems as subsystems, use of standard parts, and 
maintainability by unskilled technicians, 
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4) Constraints—the limitations imposed by specific cir- 
cumstances under which the system design job is to 
be executed. Typically these are economy, time, man- 
power, size, weight, etc. 


SYSTEM SYNTHESIS 


Assuming a thorough understanding of the system re- 
quirements has been reached, system synthesis begins. In- 
itially the search is for even one technically palatable solu- 
tion to the problem. Frequently this is a long and some- 
times unsuccessful venture. After a single technically satis- 
factory approach has been determined, variants and alter- 
natives usually immediately suggest themselves. 

From this point a parallel program evolves. On the one 
hand a simple mathematical model of the system is con- 
structed, and preliminary system evaluation begins. At this 
time the evaluation consists of parameter studies directed 
towards obtaining a relative picture of the effects on 
system performance of varying critical parameters. The 
evaluation will use both the tools of simulation and game 
theory. However, in some cases the game theory analysis 
is replaced by competitive gaming. This gaming in some 
respects is the equivalent of the child’s game of “Battle- 
ship, Cruiser or Destroyer.” The essentials are to deter- 
mine the outcome of a contest between two teams. One 
team is provided with the assumed characteristics of the 
system being tested. The other team is also granted a 
finite set of assumed capabilities. The ensuing game is ar- 
bitrated by an umpire whose evaluation provides the de- 
sired data. 

In the other, or parallel, approach, the system configura- 
tion is established by the initial design team. Many of the 
critical system design choices are made during this period. 
It is important that this work be done soundly and carried 
far enough so that the subsequent step of system design 
execution does not bring too many unpleasant surprises. If 
the initial design is soundly carried out, then the remainder 
of the task will flow more smoothly. 

The composition of the initial design team is important. 
The team itself must be fairly small and coherent, and 
must be able to draw on the organization’s technical re- 
sources for technical inputs and recommendations. The 
output of the team is a system design document and con- 
figuration for the over-all system, including requirements 
and performance estimates for all subsystems. 


SysTtEM DESIGN 


Having established the preliminary system design to 
the point where it has passed the test of technical feasibility, 
and where it has been reasonably optimized by the evalua- 
tion team with respect to such factors as effectiveness, 
cost, reliability, etc., we come next to the problem of sub- 
dividing this rather broadly defined package into smaller 
packages, called subsystems, sub-subsystems, and com- 
ponents, which can be worked upon by a large body of de- 
signers of the actual hardware. The package in each case 
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must be discretely defined, such that minimum coordination 
between design groups is required. In other words, each 
package must not have too many strings sticking out that 
have to be knotted jointly with other groups. 

Each subsystem definition must spell out: 

1) The performance required. 

2) The functional relationships to other subsystems and 

to the over-all system. 

3) The test requirements. 

In approaching this problem we must first be sure that 
the over-all system performance requirements as estab- 
lished by the preliminary design group are thoroughly 
documented. This document is the base line from which all 
work stems, and it must be maintained in a current—there- 
fore dynamic—state throughout the life of the design ac- 
tivity. Next, we must make our initial definition of the 
performance requirements of the major subsystems, their 
sub-subsystems and finally, component performances, as 
required to provide the over-all system performance, At 
this point it should be emphasized that these requirements 
must remain flexible during the course of design progress, 
in order that performance deficiencies which are bound 
to show up in design and test of some subsystems and com- 
ponents can be accommodated by the extra performance 
achieved in other areas. 

In addition to the performance requirements of the sub- 
system and components, we require definitions of the func- 
tional relationships between the various subsystems, again 
on a flexible basis which can adapt to new knowledge as the 
design progresses. These relationships between subsystems 
are variously called interties or interfaces. In general, the 
more sophisticated the system, the more interties it re- 
quires. When we ask that a system respond to a given 
situation with great rapidity and, in addition, in a manner 
which varies with small differences in a large number of 
factors, we are increasing the subsystem interties required. 
To illustrate, consider a passenger elevator. If we assume 
that it operates only between the first and second floor and 
that it has light traffic, it can respond more slowly to a sim- 
ple pushbutton switch and use a simple off-on electric 
motor. If it must operate between several floors with high 
traffic, we want it to operate much faster to provide ade- 
quate service. No longer can we use a simple off-on motor, 
sO we must provide control circuits which assure smooth 
acceleration up to high speed and smooth deceleration. 
Also, the control system must sort out the floor from which 
the signal comes. Now we’re getting a number of interties 
between various parts of the system. The size of any sys- 
tem design job is a function of the number of interties 
between the parts of the system which in turn are governed 
by performance requirements (as in the elevator example). 
It is also a function of the size (number of subsystems) 
of the system. If, for example, we take a battery of our 
high-speed elevators in an office building and ask the con- 
trol system to dispatch the elevators automatically, taking 
into consideration the number of people ringing at different 
floors, the time of day as to whether people are coming to 
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work or going home, how full each elevator is in picking 
up passengers during descent, etc., we have a much larger 
and more complex system, 

Our experience shows that good systems engineering re- 
quires a strong effort to keep the number of interties to a 
minimum in the interest of compressing development time, 
maintaining system reliability and achieving flexibility 
together with minimum development cost. It is most im- 
portant to analyze these intersystem relationships and sys- 
tematically reduce them until it can be shown that further 
reduction will have an unacceptable system performance 
degradation. There is a definite limit to the total com- 
plexity of a system which can be developed on a reasonable 
time scale, regardless of the man-power applied. The total 
complexity is directly related to the number of interacting 
functions or interties between various parts of the system. 
A very large system employing large numbers of designers 
can be effectively managed only if the number of inter- 
actions between its parts are kept down. 

At this point it is interesting to consider how man affects 
the problem of functional relationship between subsystems. 
Man is a flexible, if somewhat performance-limited, ma- 
chine. He is especially useful in minimizing system com- 
plexity if his performance limits are not exceeded. Let’s 
go back to our elevator illustration. An elevator starter 
with average intelligence and limited training does a highly 
satisfactory job of elevator dispatching when he mentally 
juggles the factors of time of day, present positions of ele- 
vators, load density of the various floors, etc. As a result, 
such an elevator system provides service almost as effective 
as an all-automatic one and is certainly much simpler. 

Having defined performance and functional require- 
ments for the subsystems, we should now mention test re- 
quirements for these same elements. We cannot do an in- 
telligent or even a workable job of component or subsystem 
design without considering the tests required and the man- 
ner in which the parts of the system will be assembled 
and tested. The test requirements must recognize the need 
to insure performance of each portion of the system, its 
proper function, its reliable operation under operating en- 
vironments, and the compatibility of the testing with that 
performed on other system elements and on the assembled 
system. 

We have discussed the requirements for organizing a 
system design job in terms of packaging the parts of the 
system for the design groups to go to work on. This has 
required a definition of performance and functional and 
test requirements. There is, however, one more aspect 
of work organization which should be considered, which is 
the scheduling. In order to keep control, the scheduling 
must be given top billing. To do this, we start with the 
over-all schedule indicating final system test dates required 
and work back to establish the dates for subsystem and 
even component testing. It is obvious that all the dates may 
have to be juggled several times in order for a compatible 
set to emerge. This process forces close attention to be 
paid to the realistic availabilities of components. The re- 
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sulting schedule, when approved by top management, is 
called the “master’’ schedule and can be modified only by 
top management. Equivalent schedule control is required in 
production. 

The importance of scheduling is generally well recog- 
nized, but there are two facets frequently overlooked, The 
first is to make sure that all items of the system are in- 
cluded. Those most frequently missed are the support and 
test equipment in final product form. Support and test 
equipment as required for the development program is 
usually provided for, but the design of the production ver- 
sion is frequently missed in the initial scheduling, Con- 
sequently, it becomes the bottleneck in production and 
in effective use of the system in the field. The second item 
often neglected is flexibility in the schedule. Things never 
go as planned, and the schedules must take into account 
alternate ways of proceeding without affecting the final 
dates when one or more delays are encountered in some of 
the component or subsystems development. 

The designers, m proceeding, must tackle the toughest 
and least certain parts of the problem first. Analysis and 
test should be programmed to yield critical answers at the 
earliest possible dates. As the design proceeds and pro- 
vides answers on the performance realized by the various 
components and subsystems, these answers (both better 
and poorer than expected need to be coordinated with other 
subsystem design groups to rebalance the performance of 
the entire system. This in turn will cause a readjustment 
of the performance and intertie relationships originally set 


forth for the various subsystems making up the entire sys- . 


tem. 
SYSTEM TESTING 

System testing covers not only factory and field testing, 
but also development testing. 

It makes sense for the system designers to be respon- 
sible for the design of factory and field test equipment 
and for the test requirements and procedures which go 
with the testing. In every case we hold our own designers 
responsible for test requirements, even in those cases 
where the subsystem may be the responsibility of another 
company. In such cases, the other company should design 
and furnish the equipment for factory and field tests for 
their subsystems. The present trend is to have more and 
more of the subsystems designed and furnished by other 
companies, either as government-furnished subsystems or 
by subcontract. In either case, the prime contractor’s role 
is becoming one of the assembling and testing the system, 
while manufacturing very little of it. Largely as a con- 
sequence of this, our factory layout is governed by the re- 
quirement of orderly assembly and test sequences. 

We use a method in our operation which has several 
levels of test, in which the component tests may be level 
6 and the smallest assembly of components may be level 
5, building up larger subsystems at lower test level num- 
bers until the final system test may be level 0. 

It is obvious that with this kind of assembly and test pro- 
cedure there is a problem of performance tolerances which 
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is analogous to the tolerance problem on mechanical parts. 
The total system tolerance on performance is broken down 
in a systematic manner to the successively lower test levels. 
The tolerance on the small assemblies must be narrow 
enough so that when they combine with the tolerance of 
other subassemblies at a higher level they do not finally 
exceed the acceptable deviation for the entire system. 

Fig. 2 shows percentages of floor area devoted to as- 
sembling and testing in a typical case. In choosing the 
number of test levels during the assembly process, we at- 
tempt to minimize the total time and cost of testing. If no 
tests are performed until final assembly there are bound 
to be many faults which are difficult to isolate and the as- 
sembly line gets clogged. On the other hand, the subsystem 
tests are also time consuming and costly, so there is an 
optimum number of test levels. 
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Fig. 2—Typical factory floor area requirements—for assembling 
and testing—excluding office space. 


Regardless of what other test equipment may be used 
in the factory during the assembly process, the last check- 
out is performed on system test equipment which is identi- 
cal to that furnished the customer for his use in the field. 
It is also wise to test in the factory to a tighter set of 
tolerances than is allowed for use in the field, This will pro- 
vide some compensations for the degradation which occurs 
due to drifts with time, or less skill in field testing. 

While there are many facets to development testing, 
such as component tests, breadboard tests, subsystem lab- 
oratory tests, etc., it is the flight test programs which are 
most interesting, meaningful, and visible, at least in missile 
development programs. We are able to identify three types 
of testing in missile flight test programs, namely, evalua- 
tion, demonstration, and exploration. This does not mean, 
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however, that each separate missile flight is flown exclu- 
sively for one of these purposes. In fact, many flights com- 
bine all three purposes. Evaluation tests, in the sense used 
here, are used to measure development progress in a gross 
sense since the successful ones verify the analytical pre- 
diction of system performance. They also serve to give 
confidence to the top technical management and the cus- 
tomer. The designers of the subsystems develop their con- 
fidence by the results of component and subsystem testing, 
but since the technical managers and customers are not so 
close to the subsystem test and analysis, they look to the 
flight tests for their evaluation of development progress. 

In this connection, the authors have found that most 
designers are conservative and will advocate taking rela- 
tively small steps in the flight test program. It becomes 
necessary for those responsible for the work to force 
larger steps than the designers recommend. For example, 
the designer of a subsystem, such as an element of the 
guidance system or an auxiliary power plant, wants to fly it 
in the missile and telemeter back its behavior during sev- 
eral flights, before he is willing to hook it in as an operat- 
ing part of the system. Our experience says that the right 
answer is to make all elements of the system operational 
parts just as soon as the hardware is available for flight. 
If the design and ground tests have been done well the 
parts will work in flight, and time and expense will be 
saved by reducing the number of figures required for the 
program. 

Using this philosophy in one missile development pro- 
gram, only 18 missiles were required to prove the integrity 
of the basic airframe and propulsion. The guidance con- 
cept verification required 6 additional missiles. At the be- 
ginning of the program many people predicted it would 
require dozens or hundreds of missile flights to reach the 
same point. 

Demonstration flight tests, under our definition, are 
those which show the customer that the system will meet 
the contract performance guarantees, that all elements of 
the system, including the support and test equipment, will 
function properly, and that the system is usable by the 
customers’ personnel. These demonstrations normally cul- 
minate in tests performed by customer personnel prepar- 
ing and operating the system using production prototypes 
of all items of system equipment. 

Exploratory testing is that testing which is designed to 
find the performance limits to the system. It is of more 
immediate interest to the design engineer than to the cus- 
tomer, but it is most necessary for exploiting the growth 
potential inherent in the system. When subjected to limit 
testing, most of the system will prove to have more than 
design performance. By fixing up the weak spots, the sys- 
tem performance can be greatly improved at little cost in 
weight or complexity. As a rule, missile designers feel they 
have more difficulty than they should in getting exploratory 
flight tests scheduled. One of the reasons for this is that 
this limit testing often results in spectacular failures, such 
as structural breakups or explosions, when the limit is 
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reached. Since missile flight tests are usually quite visible 
to the press and public, the customer doesn’t relish testing 
which courts publicly visible failures, no matter how wor- 
thy they may be. In fact, the design organization, par- 
ticularly if it is part of a company making consumer prod- 
ucts, is also reluctant to have unfavorable publicity. For- 
tunately, we have been quite successful in combining test 
objectives wherein the exploratory or limit testing is done 
late in the flights, after the demonstration objective has 
been accomplished. Maximum range tests and maximum 
maneuver acceleration tests are typical of those which have 
been done. 


SystEM EVALUATION 


Other than live system testing, the two main facets of 
system evaluation are: 

1) System performance determination 

2) System application analysis. 

Both of these contribute to the understanding of the sys- 
tem’s inherent capabilities and its useftilness for any pro- 
posed application. 

System performance determination is basically the meas- 
urement of the system’s ability to accomplish the job for 
which it has been designed. The tools required include 
facilities (analog, digital, or both) and a trained analytical 
staff. The use of simulation techniques as a design and 
evaluation tool is well known. Extensive digital simulation 
of complex systems requires considerable effort and time. 
Consequently, analog simulation techniques are used as 
well as digital. In the early stages of system design it 
is still necessary to combine analytical or graphical 
predictions of subsystem performance with estimates of 
over-all system performance. This situation is required by 
the lead time necessary to prepare the appropriate digital 
or analog simulations. Extensive simulations allow us to 
study the behavior of a system as significant parameters 
are varied to an extent that would not be possible by actual 
system tests. It has been our experience that analog simula- 
tions are primarily valuable for giving insight and im- 
proved understanding of a problem, but that digital tech- 
niques are required for accurate analysis of complex sys- 
tems. There is much progress yet to be made before simula- 
tion techniques contribute their full potential to system 
design. 

System application analysis or operation analysis relates 
to the study of the behavior of the system in the environ- 
ment in which its use is planned. Exterior factors affect the 
performance of the system in a specific application, and re- 
sults are obtained which apply only to the particular ap- 
plication being considered. These studies may reveal de- 
ficiencies in the system which should be removed for effec- 
tive over-all performance. These studies may be considered 
as “outwardly” motivated, rather than “inwardly” moti- 
vated as are the system performance studies. The commer- 
cial airlines make extensive use of operation analysis tech- 
niques. Paper airplanes are flown over specific commercial 
routes to establish the economics and other features under 
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changing weather, traffic load, schedule arrangement, and 
other variations. These studies help the airlines establish re- 
quirements for new airplanes. After a specific airplane has 
been ordered, the studies are intensified to provide an 
evaluation of the potential value of the airplane to the line 
and to determine the optimum manner of applying the air- 
pane to the routes to be served, 

These studies determine how many of a given type of 
aircraft should be ordered, how much ground support 
equipment will be required, and what fares and load 
factors are necessary for over-all profitable operation. 
Mock-ups of the aircraft are built by the customer air- 
line in addition to the airframe manufacturers, These are 
used to experiment with seating arrangements, meal facili- 
ties, stewardess requirements, etc. 


MANAGEMENT 


System management implies a “cradle to grave’ re- 
sponsibility. In the systems engineering field this means a 
continuity of work from first concept stages through to 
final obsolescence of the last articles in field use. Ability 
to provide this systems engineering and management func- 
tion is unique with commercial manufacturing organiza- 
tions. Only these organizations have both the incentive and 
the mechanism to carry such programs through. 

The organization to accomplish the development and test 
of large systems can take many forms. There are, how- 
ever, certain basic requirements, which are perhaps ful- 
filled only by organizations which undertake large system 
design responsibilities. First, the organization must be 
fluid, to provide growth for individuals without loss of 
their experience to the program. This is essential because 
of the length of time required to complete each program 
and the relatively few major programs under work. Second, 
the organization must evolve as the program goes from 
the early concept and design stages through test and pro- 
duction. 

Top management must be provided assurance that the 
work is progressing satisfactorily. To this end, the organ- 
ization must provide for planning and coordinating func- 
tions, “doing” functions, and a “conscience” function. 
The “‘conscience”’ is used to keep the “doing” honest; the 
planning sets goals and monitors progress. Actual organ- 
ization tables must fit the personnel available. The organ- 
ization must accomplish the above functions to be satis- 
factory to management. 

Fitting the system function into this over-all organiza- 
tion creates many problems, as systems work cuts directly 
across normal channels of hardware design and testing. 
What is basically needed is to have, at early stages of the 
program, a system design activity which provides cohesion 
for the program. Personnel assigned to this activity must 
have a thorough understanding of the design principles and 
objectives. 

During later stages of the program, the concept is now 
firmly established and the work packages discussed above 
under Systems Design are well defined. At this point, the 
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systems design responsibility is primarily to insure both 
compatibility between subsystems, and economical and 
timely design. 

In using successfully the capabilities of other industrial 
organizations for developing large and critical subsystems, 
the key to success lies in the rigid application of a few 
simple rules. These are: 

1) Specify only the critical performance requirements. 

2) Minimize the functional interties with other sub- 
systems and then specify this minimum as require- 
ment. 

3) Specify the philosophy to be used in such matters as 
reliability, design trade-offs, growth potential, flexi- 
bility, etc. 

4) Let the other organization execute the design on its 
own. 

5) Maintain careful monitoring of progress by noting 
the achievement or lack of same for preselected 
key development progress points. 

If this monitoring shows the subsystem development to 
be in trouble, insist that the responsible company fix its 
difficulty. Do not try to do it for him by taking over. It 
often seems easier to get in and do the job yourself—but 
do not. It only leads to more trouble. Sometimes we have 
found that it is necessary to provide temporary help in 
the form of skilled engineers, managers, and shop people. 
This must be done on the basis of their working for the 
management of the company in trouble, with care taken to 
see that they report to the correct management level. Our 
theory is to help him to get out of his trouble, not to 
solve his problem for him. We know this is the way to 
get strong and willing partners. 


System Costs 


Costs, of course, are of paramount importance in the 
implementation of a military system. It is essential to have 
early in the design and implementation a realistic under- 
standing of the extent of funding available to achieve a 
particular mission. For example, there is competition for 
funds for offensive and defensive missions. National mili- 
tary policy coupled with government economic policy 
determines the extent of funding available for offensive 
weapons. Again, within the offensive aircraft and missile 
mission there is competition for funds between long- 
range bombers, carrier-based reconnaissance aircraft and 
missiles, submarine-based missiles, ICBM’s, and IRBM’s. 

Development costs of large-scale military systems be- 
come very large, and in fact can exceed production costs 
if only small quantity production runs are procured. This 
obviously is an undesirable situation, which hopefully can 
be avoided by realistic planning. 

We often hear the argument that a particular weapon 
system development was worthwhile from the viewpoint 
of knowledge gained and capabilities established, even 
when implementation was not carried out. We submit that 
this is an expensive form of development. There is a 
need, however, for judicious funding of critical component 
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developments without requiring these developments to be 
justified in all cases by being a known part of a weapon 
system. 

Production costs with complex military systems tend 
to go down a rapid learning curve. As a result, increased 
procurement quantities can be achieved with significant 
savings in dollars. In fact, in typical cases increases of 
100 per cent in production orders may only result in a 
331% per cent cost increase if the quantities are procured 
over the same total time period. This bears very strongly 
on the problem of major system changes. 

Although a new model of a military system may be 
technically available, building it is not always desirable 
if the same objectives can be achieved with the older model 
even at the expenses of more required equipments. In this 
case we balance up the costs vs the effectiveness per unit. 
These trades must be judged differently if extremely high- 
level performance systems are desired. For example, if 
the mission demands nearly 100 per cent success, different 
answers would be reached. 


COMMITMENTS TO PRODUCTION 


Complex systems are characterized by the long lead time 
required from the initial concept to the time at which a 
significant quantity of equipment is in operational use. 
The lead time is not directly proportional to the com- 
plexity, but it is a function of the complexity, the degree 
of state-of-the-art improvements required, and the manner 
in which the design and implementation job is attacked. 

Procurement policies which are based on a proven 
prototype test preceding production ordering are reason- 
able and adequate for military purchase of systems of a 
low order of complexity. These policies, however, are com- 
pletely inadequate for achieving operational readiness of 
complex military systems. It has been our experience that, 
if the basic technology is understood and if the feasibility 
of the concept can be established by analysis and test, 
then a severe penalty results from waiting until complete 
production prototypes are available before committing a 
system to production. 

Systems consist of many equipments, some of which 
will be found initially to be poorly conceived or executed 
in design. In all cases, however, the over-all system can be 
made to work, with the recognition that problems are 
present in specific areas. The supposed saving of waiting 
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until a complete design can be chosen and proven before 
commitment to production is more than balanced by the 
true cost of producing equipment several years later than 
is otherwise possible. In fact, all successful weapon sys- 
tems which have had large-scale use in this country in 
the past fifteen years have been committed to production 
prior to availability of completely engineered prototypes 
with all the supporting data and handbooks. 

This point is belabored here in the hope of destroying 
false illusions of economies and savings. The greatest 
economy is not to do the job at all. If the job needs doing, 
then production commitments can be made with confidence 
early in the development program. Care must be taken, 
however, to prevent these commitments from causing 
premature design freezing or unnecessary rigidity in the 
development program. This leads naturally to the subject 
of the next section. 


CHANGES 


Control of changes is a very difficult problem during a 
system development and production program. On the one 
hand, everyone recognizes that changes are necessary ; 
on the other hand, no one wants to go to the trouble of 
making them. The costs of changes are greatly amplified 
by the amount of coordination necessary to insure that the 
system will be compatible after the change has been ef- 
fected. Normal procedure is to establish change boards 
which have representatives from each department of the 
organization. These change boards are responsible for 
putting together a complete description of a change, the 
effect of the change on other parts of the system, the cost 
and timing associated with the change, and the benefits to 
be accrued, based on all these factors. A decision can then 
be reached, and the change ordered or not. The key to suc- 
cessful control here lies in the clear definition and establish- 
ment of subsystems in such a way as to make them as 
mutually independent as possible. Whatever the change 
procedure adopted, firm control is necessary to avoid chaos. 
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Weapons Systems Management* 
T, L, PHILLIPS} anv I. A, GETTING} 


INTRODUCTION 


T IS a platitude that any successful weapons system 
requires inspired engineering leadership characterized 
by sound judgment and a broad understanding of 

military needs. In the following comments the formal as- 
pects of weapons systems engineering are presented. While 
these formalized steps are essential to a successful sys- 
tem, at each step there is also the need for compromise 
or innovation. Lack of judgment where a sensible com- 
promise is required can result in a monstrous system. 
Lack of innovation and inspiration cen result in a stale 
system. 

The very word “system” implies a coordinated and 
consistent engineering task. Leaving out for the moment 
such aspects of prudent engineering as reliability, stand- 
ardization, and due respect for peripheral details that in- 
clude spare parts, instruction books, test equipment, etc., 
there still remains the need to integrate the main task at 
hand. In general, a weapons system has to perform some 
task. In modern weapons systems, this task is generally a 
complex one involving many interrelated technical features. 
It is, in general, the realization of this one fact which has led 
to systems engineering in which the over-all technical man- 
agement responsibility is placed in one person or agency. 
This is in contrast with earlier systems of management in 
which various military items were designed and pur- 
chased independently, and the system was then put to- 
gether by operational people to form a military entity. 
Such a system prevailed when field generals deployed in- 
fantry, cavalry, and field artillery. There was very little 
engineering relationship between the saddles, the pistols, 
and the mortars. On the other hand, today military 
weapons such as missile systems combine aerodynamics, 
electronics, propulsion, explosives, and ground support 
equipment into an internally consistent dynamic and kine- 
matic system. Harold Hazen of the Fire Control Section 
of NDRC during the war quite properly stated that present 
weapons systems are generally defined by high order 
differential equations. The old concept of separate engi- 
neering and procurement is comparable to taking such a 
differential equation and contracting out each separate 
term, term by term. It is not surprising, therefore, that 
the solution consisting of such independent attempts at 
solution was equally monstrous. 


PLACING RESPONSIBILITY AND DEFINING THE PROBLEM 


A new weapon system is born with the requirement for 
an advanced tactical, strategic, or defensive capability. The 
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requirement is operationally defined by a set of military 
characteristics usually prepared by the using agency of 
one of the three services. The characteristics define such 
broad parameters as the primary and secondary missions, 
the operational environment, the desired range, effective- 
ness, reliability, and degree of mobility of the system. 

The major burden of system engineering falls on the 
technical agency and the prime contractor in varying 
amounts depending on the particular service and the 
type of weapon system. It is important that the role and 
responsibility of each be well defined early in the develop- 
ment. Proper system engineering is feasible either for 
the case wherein the technical service is strong enough 
to retain technical control of the system, relying on 
industry only for manufacture, or for the case wherein 
systems control is assigned to a strong prime contractor 
when development is initiated, and broad latitude is al- 
lowed toward the solution of the problem. In either case 
the responsibility is clearly defined, which is of the utmost 
importance. The great danger comes when a technical 
agency or government laboratory is not strong enough 
to manage a complete program, but still desires to dabble 
in it. In this case, responsibility cannot be clear and an 
inferior product delivered on a delayed time scale is the 
inevitable result. A great many weapon developments 
drift into management along this compromised middle 
road. It is a compromise of expedience and a leading 
deterrent of proper system engineering. 

Assuming the responsibility is defined, the next step is 
to define the problem. The operational characteristics of a 
weapon system must be translated into precise technical 
requirements. We must ask ourselves early, ‘“What are 
the precise technical problems we are trying to solve?” 
In doing this many times the answers are readily forth- 
coming and we avoid vague solutions of imaginary prob- 
lems which often result from inadequate definition. 

A weapon system implementation is divided into four 
time phases as follows: 

1) Feasibility study 

2) Critical component development 

3) Prototype development 

4) Production. 

Sometimes it is difficult to recognize the distinct division 
of these phases, especially in an accelerated program. How- 
ever, for purposes of this paper, we will assume the division 
to exist. 


y 


FEASIBILITY STUDY 


During the feasibility study, a system engineering 
nucleus of key people must be assigned to the problem. 
These people should have the broadest possible systems 
experience, although men with specialized technical pro- 
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Fig. 1—Readers may be interested in this photograph of the Lab- 
oratory, breadboard XT-1, which became the SCR-584 in production. 


ficiency in such major fields as radar, infrared, com- 
munications, controls, aerodynamics, propulsion, and 
armament must be included. Clearly, the feasibility study 
is a time for concepts and ideas, with conceptual thinking 
being stimulated by a free exchange of ideas. Often many 
ideas will not be feasible, and the best critics in pointing 
this out will be nonoriginating members of the same group. 

After the number of approaches is narrowed down, 
often two or three will still appear to be feasible. Here 
the methods of operations research and analysis must be 
called on to evaluate competitive solutions and choose an 
optimum one. To accomplish this, simplified mathematical 
models are used and comparisons are made based on 
several criteria, such as reliability, cost, weight, mobility, 
etc. However, operations research is no better than the 
assumptions which are made, and to the extent that these 
assumptions may become more and more involved, the 
results of these studies must be carefully evaluated as to 
their realism. Often a decision may be required which, 
while guided by the results of the study, will nevertheless 
be based primarily on the experience and judgment of the 
systems engineer. 

It is the object of the feasibility study to choose an 
optimum way of accomplishing every objective of the 
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Fig. 2—Of historical interest is this photograph of the first fully 
integrated automatic radar tracking fire control system in the 
Navy—GFCS MK. 56. 


system. From this point on, every major parameter of the 
system is defined. It may subsequently prove that unwise 
selections were made, and alternate solutions must be 
explored. These explorations must then be made in 
parallel and on the side, while the major system de- 
velopment proceeds along its designated path. Should an 
exploration prove to find a solution more desirable than 
the one designated in the defined system development, 
this is then substituted for the inferior solution. The 
important thing is that after the feasibility study there 
be but one established approach to any particular problem 
at a given time, and that this be defined in all of the 
pertinent design data manuals. Only.in this way can a 
complex weapon system be designed with compatible 
components by design agencies often laboring in well- 
separated geographic locations. 

A second objective of the feasibility study is to evalu- 
ate the effectiveness of the weapon system as defined at 
the end of the study. Measures of effectiveness in graphi- 
cal form must be available, depicting such parameters as 
zones of effectiveness, kill probability, rate of fire, system 
costs, manpower requirements, mobility, transportability, 
and the maintenance and support plan. 
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During and at the end of the feasibility study, careful 
reviews should be made of the system with the using 
agency. These reviews are usually in the form of pres- 
entations or conferences and are of the utmost importance 
in the development cycle of the system. Without these 
reviews it is not possible for the contractor to anticipate 
and interpret all of the operational requirements the user 
has in mind, nor is it possible for the user to anticipate 
the contractor’s method of approach and its effect on his 
requirements. 

After the feasibility study, arrangements must be made 
for periodic reviews wherein contractor and user have a 
chance to exchange ideas, Without this cross fertilization 
of ideas, science and industry might well develop techni- 
cally superior weapons that are operationally of very little 
practical value to the user. 


CRITICAL COMPONENT DEVELOPMENT 


The next phase of the development cycle is that of criti- 
cal component development. There are two reasons why 
this phase is separate and distinct from prototype develop- 
ment. 

The first is that the weapon system requirement has 
become so critical that there has not been time for basic 
research to supply all the tools necessary for the system’s 
realization. Therefore, in certain critical areas the weapon 
system is pushing the state of the art, and critical com- 
ponent development or accelerated research must be ac- 
complished to ascertain its feasibility. 

The second and very practical reason is that develop- 
ment programs are not always adequately funded. In 
this case, choices must be made on those components whose 
development on an early time scale is most necessary, 
either because of lead time or their critical nature. For ex- 
ample, a missile airframe must be developed before a 
means of handling it, and a guidance system, before a 
means of maintaining it. 

During the critical component development phase or 
earlier, some of the major subcontractors of the system 
will be engaged. Indoctrination of the subcontractor in the 
system philosophy is a very important task. One par- 
ticularly effective way of accomplishing this is to invite the 
subcontractor’s key people to spend a period of two to 
three months at the prime contractor’s facility, and ac- 
complish there most or all of the preliminary design. Dur- 
ing this phase the compatibility of the design is assured, 
and the mode of operation and liaison ties are established. 

For effective subsequent liaison the prime contractor 
must be staffed with men expert in the technical pro- 
ficiency of the subcontractor. They have the important 
role of continually reviewing the subcontractor’s design 
and continually interpreting system requirements in a 
technical language which the subcontractor can readily 
understand. 

The question is often raised as to how much the prime 
contractor should subcontract out and how much he should 
retain for in-house development. That there will be sub- 
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contractors in the development of a major weapon sys- 
tem almost goes without saying, because the complexity 
of today’s weapon systems is such as to make it extremely 
unlikely that a single contractor possesses all of the neces- 
sary skills within his organization. 

On the other end of the spectrum, it has become popular 
to consider prime contractors who subcontract all develop- 
ment and perform only a management and coordination 
function. There is a danger in this approach, however, 
since the prime contractor cannot really have the com- 
petence to manage unless he gets his hands dirty in hard- 
ware and has tackled some of the difficult development 
problems first hand. 

Then too, the research and development phase of a 
program is not financially rewarding to a profit-motivated 
industrial concern. Therefore, it becomes important for 
the prime contractor to retain a certain percentage of the 
weapon system development in the house to reap some 
of the financial rewards of subsequent production. This 
also affords the allocation of the highest calibre develop- 
mental people and retains the enduring support of manage- 
ment. 

Considering both these factors, it is our estimate that 
a prime contractor should retain for in-house development 
somewhere between 30 and 60 per cent of the system, 
depending on the particular situation. 


PROTOTYPE DEVELOPMENT 


The prototype development is a phase which must 
culminate in a complete system demonstration and lead 
directly to production releases. It is also the phase where 
reliability will or will not be designed into the system. 

Of course, reliability begins with the basic concept of 
the system. If the basic concept is marginal, or if it 
simultaneously requires an unreasonably high degree of 
performance on a number of its elements, such a system 
will be operationally unreliable. The stress of war and 
the general deterioration of equipment in field use demand 
margins of safety in concept. 

In addition, the designer must design adequate margins 
of safety into each of the component parts. However, as 
a double check a Quality Assurance Department must be 
available to evaluate all aspects of a given design. These 
include not only what is normally considered reliability, 
such as the ability of components to withstand environ- 
ment with safety margins, but a complete evaluation of 
the degree of sophistication of the design and the ease 
of its testing, handling, and maintenance. 

Where missile systems are concerned, design evaluation 
is extended one more stage to the flight test facility. Here, 
especially where complete systems are assembled and firing 
operations are conducted, it is important that the con- 
tractor have high calibre personnel capable of evaluating 
design deficiencies and reporting them back to the home 
plant for corrective action. 

With three layers of design evaluation and rapid re- 
action it is possible to eliminate at an early date those 
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design flaws which would otherwise have crept into the 
system. 

The center of project control and decision is the project 
engineering team which was established during the early 
phases of the feasibility study. This team must bring the 
design specialists together to evolve a compatible design, 
must enforce corrections of design deficiencies, must 
maintain liaison with the flight test facility, the production 
facility, and the government agency, and must establish 
and maintain system schedules. 

The key man in the project team is the senior project 
director. In a complex weapon system, rule by committee 
is not possible. Somehow, in any system one man must 
accept responsibility for decision and for the ultimate 
outcome of the development. The natural attributes of this 
man must qualify him to lead, to stimulate, to inspire a 
team spirit, and to promote. 

A seldom recognized attribute, however, is also the 
ability to say “NO!” In every large research and de- 
velopment organization, there is a plentiful supply of 
ideas and inventions. Some of these ideas buy a great deal 
in capability and contribute greatly to the effectiveness of 
the weapon system. Others, while adding some effective- 
ness to the system, do so at a high cost in complexity and 
a significant reduction in reliability. Still others, while 
adding effectiveness, do so in a time scale to affect produc- 
tion schedules or seriously alter the logistic and support 
plan. It is the duty of the senior project director to evalu- 
ate these “improvements” carefully and unemotionally 
and to keep the program from being sidetracked by 
changes that would delay its timely availability or would 
otherwise have a detrimental effect on its operability. 

We would hate to see the system where every “improve- 
ment” that was ever conceived became incorporated into 
hardware. 

PRODUCTION 


The production phase of a weapon system is a difficult 
one because it is very seldom initiated with completely 
frozen design information. To delay production until this 
information is complete causes a serious lag in our opera- 
tional capability and tends toward the production of an 
obsolete weapon. The basic question is, therefore, when 
should production be initiated in a weapon system de- 
velopment? 

Experience has shown that a feasible time to initiate 
at least pilot production is immediately after a successful 
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research and development demonstration indicating that 
at least the primary objectives of the military character- 
istics have been met. 

There are many long lead time items associated with 
the initiation of production. Among these are facilities 
planning, the transfer of information in properly docu- 
mented form, the processing of tooling and test equipment, 
the establishment of vendors, and the training of produc- 
tion personnel. 

Concurrently, service activities must be conducted along 
the lines of training of key personnel and service evalua- 
tion tests of the equipment. During this preproduction tran- 
sition period, large numbers of production and service 
people become acquainted with the weapon system, but 
relatively small numbers of equipment are actually pro- 
duced. 

In the meantime the design information is not finalized, 
because of two general types of reasons. First, design 
deficiencies have been uncovered as a result of the first 
full-scale system demonstration, environmental tests, or 
the very act of phasing into production, and corrections 
for these deficiencies are considered mandatory. Secondly, 
even during the time period of the development the threat 
has changed, requiring an incremental effectiveness increase 
in the military characteristics; this change in the weapon 
system is also considered mandatory. To meet these re- 
quirements, a product improvement program is conducted 
concurrently with pilot production. This is rather a hectic 
period because releases to production of improvements 
must be made prior to initiation of the large production 
buildup. If this is done, compatibility of delivered equip- 
ment can be maintained through the media of retrofit kits 
and an alert field service organization. 

As time goes on, it becomes progressively more difficult 
and costly to retain system compatibility with major pro- 
duction changes. Hence, it becomes economical to have 
a cutoff date on all but routine changes. 

Unfortunately, the rapid advances in technology cause 
an ever increasing threat to the security of our nation. 
Thus, it may be that the system in production will not 
adequately meet the foreseen requirements. At this point, 
it is both judicious and economical to concede that the 
developed system will have a limited span of useful effec- 
tiveness, and to meet the increased threat a second gen- 
eration system must be initiated. 

And thus the cycle begins all over again. 
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Contributors 


Leighton I. Davis was born in Sparta, 
Wis., on February 20, 1910. He entered 
the United State Military Academy in 1931, 
began his flying 
training following 
graduation in 1935, 
and received his 
wings in 1936. He 
holds the rating of 
command pilot. He 
has received the M.S. 
degree from M.L.T. 

His first tactical 
assignment with the 
Air Force was as an 
engineering officer, 
Sixth Purnsurt 
Squadron, 18th Group in Hawaii. In Jan- 
uary, 1939, he became an instructor in the 
department of mechanics at West Point, and 
in 1942 helped establish the Basic-advanced 
Flying School for United States Military 
Academy cadets at Stewart Field, N.Y. The 
following year he was transferred to the 
Engineering Division at Wright Field, Ohio. 
During the next five years there he was 
technical executive to the chief of the Ar- 
mament Laboratory, and then chief. In 
March, 1948, he became chief of the Ap- 
plied Research Section of the Air Materiel 
Command, which became the Office of Air 
Research in February, 1949. After gradua- 
tion from the Air War College, he was 
named Deputy Commandant of the Air 
Force Institute of Technology, and, in 1951, 
Commandant. 

After the formation of the Air Research 
and Development Command, General Davis 
was transferred to Baltimore as Director of 
Armament. He then served as Director of 
Development until September, 1954, when 
he was named Commander of ARDC’s Air 
Force Missile Development Center. He be- 
came the Deputy Commander for Research 
and Development at ARDC headquarters in 
August, 1958. In September, when the or- 
ganization increased its efforts in basic re- 
search, his title was changed to Deputy 
Commander for Research. 

While instructor at the USMA, the gen- 
eral received the Legion of Merit for his 
development in 1939 and 1940 of electronic 
pressure-time and pressure-volume equip- 
ment used in instruction at the Military 
Academy. He received the Oak Leaf Cluster 
to the Legion of Merit in 1946 for his work 
in designing and developing the A-1 series 
of gun-bomb-rocket sights for fighter air- 
craft. The Institute of Aeronautical Sci- 
ences chose him to receive the Thurman H. 
Bane Award for 1946 for his work in de- 
veloping fire control equipment. 

He was recently awarded a patent for an 
electronic air warfare game that illustrates 
modern warfare techniques and nuclear 
weapons’ influence on target selection. 
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Ivan A, Getting was born on January 18, 
1912, in New York, N.Y. He has received 
the B.S. degree from Massachusetts Insti- 
tute of Technology, 
and the D.Phil. de- 
gree from Oxford 
University in Eng- 
land. 

As Director of Di- 
vision 8 of the M.LT. 
Radiation Labora- 
tory, he was respon- 
sible for all fire con- 
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that laboratory. 

I. A. Gerrine These included the 
SCR-584 the first 


automatic microwave tracking radar, It 
was one of the most successful radar sys- 
tems of World War II, and saw service not 
only in its primary use as anti-aircraft fire 
control, but also in tracking V1’s and V2’s 
and in controlling tactical airplanes and mis- 
siles. He was also responsible for the de- 
velopment of the gun fire control system 
Mark 56 for the Navy. This was the first 
Navy automatic integrated fire control sys- 
tem, and is still in operational use in the 
Navy. 

For these contributions, among others, Dr. 
Getting was awarded the President’s Medal 
for Merit and the Naval Ordnance Devel- 
opment Award. 

Since the war he has been professor of 
electrical engineering at M.I.T., assistant 
for development planning in the U.S. Air 
Staff, and, for the last seven years, Vice- 
President of engineering and research at the 
Raytheon Manufacturing Company. He con- 
tinues to serve as a member of various gov- 
ernment agencies. 
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Robert H. Jewett was born on April 21, 
1910 in Rice Lake, Wis. He received the 
B.S. degree in aeronautical engineering at 
the University of 
Minnesota in Minne- 


apolis. 
In August, 1937, he 
joined the Boeing 


Airplane Company in 
Seattle, Wash. Since 
1945 he has been as- 
sociated with Boe- 
ing’s guided missile 
developments. He is 
presently chief engi- 
neer and _ assistant 
general manager of 
the Pilotless Aircraft Division. 

Mr. Jewett is an Associate Fellow in the 
Institute of Aeronautical Science and a Fel- 
low in the American Rocket Society. 
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Richard A. Montgomery (S’46—A’49— 
M’55) was born on January 11,1919,in Can- 
ada. He received the B.A. degree in phys- 
ics from the Univer- 
sity of British Co- 
lumbia in Vancouver 
in 1940, and the 
Ph.D. degree in elec- 
trical engineering 
from the California 
Institute of Technol- 
ogy in Pasadena in 
1948. 

In 1951 he joined 
the Boeing Airplane 
Company, Seattle, 
Wash., where he is 
presently staff engineer of the Pilotless Air- 
craft Division, Weapon Systems Staff. In 
this capacity he is responsible for advanced 
missile systems analysis, and investigation 
and evaluation of new methods of weapon 
guidance. 

Dr. Montgomery is a member of AIEE 
and Sigma Xi. 
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Henry G. Och (SM ’57) was born in 
New York, N.Y., on March 16, 1907. 
Shortly after receiving the B.S. degree in 
electrical engineering 
from New York Uni- 
versity in 1927, he 
joined Bell Labora- 
tories, where he is 
now Director of Mis- 
sile Systems Devel- 
opment. 

His first work was 
the design of filters 
and networks for 
carrier and transat- 
lantic radio systems. 
In 1936 he trans- 
ferred to the mathematical research depart- 
ment, where he was a consultant on trans- 
mission networks and feedback amplifier 
circuits for carrier telephone systems. In 
1940 he turned to military work as consult- 
ant and designer of electronic anti-aircraft 
directors. He continued this work during 
World War II, taking part in basic system 
analysis and planning for anti-aircraft di- 
rectors and many types of radar and fire 
control computers. He later supervised com- 
puter design of postwar anti-aircraft fire 
control and radar systems. In 1952 he was 
named to head a subdepartment in airborne 
equipment design and was given responsi- 
bility for development of bombing and navi- 
gation systems. With his appointment as 
Director of Missile Systems Development 
in 1957, he assumed responsibility for the 
Nike Hercules project at Bell Laboratories, 
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As a member of the National Academy 
of Sciences, in 1957 he took part in a 
study for the Air Research and Develop- 
ment Command. He has received a War De- 
partment and Navy Department award for 
outstanding contributions to the Office of 
Scientific Research and Development during 
World War II. 

Mr. Och, who has been awarded more 
than 20 patents, is a member of Iota Alpha, 
Tau Beta Pi, and Eta Kappa Nu. 
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Thomas L. Phillips (M’51) was born on 
May 2, 1924 in Turkey. He received the B.S. 
and M.S. degrees from Virginia Polytechnic 
Institute in Blacks- 
burg, and did further 
graduate work at 
New York Univer- 
sity toward a doctor- 
ate degree. 

He has been with 
the Raytheon Manu- 
facturing Company 
for the past eleven 
years, continuously 
engaged in missile 
development. As man- 
ager of the Systems 
Department of Raytheon’s Missile and 
Radar Division, he contributed significantly 
to the development of the Navy’s all- 
weather air-to-air missile, the Sparrow III. 
For this work, he was awarded the Navy’s 
Meritorious Public Service Citation, 
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After this, he became program director 
for the Army’s surface-to-air low altitude 
missile, the Hawk. The Hawk is an inte- 
grated weapons system consisting of all the 
necessary functions from detection to de- 
struction of the target. 

For the past two years, Mr. Phillips has 
been manager of Raytheon’s Bedford Lab- 
oratory. He has served as a member of sev- 
eral government committees, including the 
National Advisory Committee for Aero- 
nautics, the Research and Development 
Board, and the Weapons Systems Evalua- 
tion Group. 


William C. Tinus (A’31—M’36—SM’43 
—F’51) was born in Chicago, Ill, on Oc- 
tober 18, 1905. He graduated from Texas 
A. & M. College with 
the B.S. degree in 
electrical engineering 
in 1928. He immedi- 
ately joined Bell Lab- 
oratories, where, dur- 
ing the early years of 
his telephone career, 
he specialized in the 
field of mobile radio 
systems for civil avi- 
ation, police, and mil- 
itary applications. He 
made major contribu- 
tions to the development of radiotelephony 
for use in these fields. 

During World War II he was responsible 
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for the development of various radar equip- 
ments, computers, and fire control systems 
for the armed forces, and served as part- 
time consultant to the War Department. 
After the war he directed several long-term 
military development projects undertaken by 
Bell Laboratories, including the Nike 
Guided Missile System for the Army. In 
1949 he was named acting director of Mili- 
tary Electronics Development. Two years 
later he was appointed director of Military 
Electronics, and in September, 1953, he be- 
came a Vice-President of Bell Laboratories, 
in charge of military development. 

He has served on many technical ad- 
visory groups for the government. At 
various times he was a member of the Radar 
Panel, the Technical Evaluation Group, and 
the Committee on Guided Missiles for the 
Research and Development Board. At pres- 
ent he is a member of the Steering Commit- 
tee of the Advisory Panel on Electronics for 
the Assistant Secretary of Defense for Re- 
search and Engineering. He is also a mem- 
ber of the Army Scientific Advisory Panel 
and the Air Force Science Advisory Board. 

In 1954, he was awarded the honorary 
degree of Doctor of Engineering by his 
alma mater. He was cited for his work in 
radiotelephony and in the development of 
ultra-high-frequency mobile equipment, and 
for his service to the government and in the 
administration of Bell Telephone Labora- 
tories. 

Dr. Tinus served on the IRE board of 
editors for six years. He is also a member 
of Tau Beta Pi, Eta Kappa Nu, and the 
American Ordnance Association. 
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